This invention relates to communication systems. More particularly, and not by way of limitation, the invention is directed to a system and method for reducing memory usage on both ends of a communication between servers in a communication network.
In communication networks utilizing the Session Initiation Protocol (SIP), such as an IP Multimedia Subsystem (IMS) network, a SIP SUBSCRIBE message is used to subscribe to changes of a state belonging to a user in the IMS network. When the User state is changed, a SIP NOTIFY message is sent from a Notifying server to the subscribing user. In the IMS network, due to scaling reasons, there are a number of SIP application servers (ASs) that each serve a number of users in a domain. The allocation of users to a certain instance of an AS is handled by the IMS network, and a Subscribing AS does not know which Notifying AS contains the User state. To find the correct Notifying AS, the Subscribing AS sends the SUBSCRIBE Message to the IMS core network which in turn routes the message to the correct Notifying AS.
According to RFC3265, it is possible to use the existing “id” parameter of the Event-header, in order to have multiple subscriptions in one dialogue. Nevertheless, a large amount of memory is still needed to store SIP dialogues. One reason is that using the “id” parameter means that subscriptions within the same dialogue must share the same watcher and target since there is no way to identify them other than using the To and From headers of the dialogue. So this makes it impossible to use the same dialogue for subscriptions with different watchers and targets. Therefore, a number of SIP dialogues must be set up between a Subscribing AS and a Notifying AS. The dialogues are maintained during the lifetime of the subscription. A dialogue may exist for an extended period of time, even though the number of NOTIFY messages sent may be rather low during the lifetime of the subscription. Still there is often a need to have a NOTIFY message sent in real time. Therefore, a pull-based solution is not preferred.
Examples of states that are handled in this way are Presence and XCAP document changes as defined by IETF, 3GPP, and OMA standards.
The existing solution forces the Subscribing and Notifying ASs to keep one state for the Subscribe dialogue per user and AS. Every dialogue requires some memory usage. Assuming, for example, there are one million users in an IMS domain and 100,000 users allocated per AS, this means that there are ten Subscribing ASs and ten Notifying ASs. If every user is subscribing to one other user, there will be one million SIP dialogues. As an example, if every dialogue requires 2 Kbytes of basic memory per AS, a total of 2 Gbytes of memory will be required for the dialogues. If it is assumed that every user subscribes to ten other users, as can be the case between a Resource List Server (RLS) and a Presence Server (PS), then 20 Gbytes of memory will be required, and so on.
Thus, it can be seen that the number of sessions set up between the RLS and the Presence Server as well as the RLS/PS and different XML Document Management Servers (XDMSs) may be very high, and the more contacts that are used, the more sessions are needed. Memory usage rather than the number of transactions per second is the larger problem in this scenario because the frequency of NOTIFY messages is assumed to be quite low.
What is needed in the art is a system and method for reducing the amount of memory required for storing SIP dialogues. The present invention provides such a system and method.